The Evolution of Braille: 


Can the Past Help Plan the Future? 
A three-part article from the Braille Authority of North America 
Part 2 


Part one of this article gave an overview of the vast changes that have occurred 
in both print and braille in the last few decades. This installment provides 
background on the Braille Authority of North America as well as a glimpse into its 
deliberations. The article also offers perspectives on the challenges of producing 
braille today given current codes and current production methods. 


The Workings of the Braille Authority of North America 


The mission of the Braille Authority of North America (BANA) is to assure literacy 
for tactile readers through standardization of braille and/or tactile graphics. 
BANA's purpose is to promote and facilitate the use, teaching, and production of 
braille. It publishes rules, interprets those rules, and renders opinions pertaining 
to braille in all existing and future codes. It deals with codes now in existence or 
to be developed in the future, in collaboration with other countries using English 
braille. In exercising its function and authority, BANA considers the effects of its 
decisions on other existing braille codes and formats, the ease of production by 
various methods, and acceptability to readers. 


The board of BANA and all of its committees are made up of educators, 
transcribers, braille producers, and braille readers. More than 100 people are 
involved in BANA's work. 


As language changes, the need for new ways to represent things in braille 
continues to raise the need for new symbols and new uses of current 

symbols. Braille readers need access to the same information as do their print- 
reading counterparts in this age in which the norms for printed material are 
evolving rapidly. 


Despite the need to respond to the changes in language, making changes in 
braille is not easy. BANA must deliberate very carefully before making even small 
changes to braille. It is essential that BANA consider the impact of any changes 
on readability, "writeability" (that is, how easy it is to write the code using various 
tools), computability (which refers to how accurately it can be translated and 
represented electronically), space considerations, familiarity to current braille 
readers, and so on. There are many goals to balance, and not all of them can be 
achieved effectively all of the time. The benefits of making any change must be 
shown to outweigh the drawbacks. For example, when the term and icon for the 
euro were adopted in Europe in 1995, a braille symbol had to be invented to 
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represent that new print symbol. In 2007, BANA adopted new symbols for 
copyright and trademark; before that, the practice had been to spell out the word, 
even though a print symbol was used in the original text. BANA cannot ignore the 
changing conventions of print without putting braille readers at a significant 
disadvantage. The current process of "keeping up" has been to add new symbols 
as they come up, but with each new symbol and each new rule change, more 
ambiguity and more conflict are being created in braille. An example of this is 
given later in this article. 


The following case provides a look into the workings of one of the BANA 
technical committees and the process through which decisions are weighed and 
made. Each technical committee of BANA works on various "charges" regarding 
changes and clarifications to a particular braille code. The committees work via 
e-mail and teleconferences, and provide written reports of their progress to the 
BANA Board for each of its semi-annual meetings. The Literary Braille Technical 
Committee was working on the seemingly simple task of deciding how to show 
partial emphasis of a word. Partially emphasized words—that is, using indicators 
to identify bold or colored print or other font changes—are appearing with 
increasing frequency in elementary school textbooks, as well as in other 
materials that include challenging text such as product brand names, mentioned 
later in this article. The committee’s report to the Board in the fall of 2006 
included the following informal narrative as an illustration of the process by which 
the committee members approached this task. Read along and follow their 
thinking as they attempt to solve this issue: 


e First: We decide, following our principles, not to add a hyphen to signal the 
transition between regular print and italic or fully capitalized print, giving 
the braille reader more accurate information about the print text. Of 
course, we all want to do that. 


e Second: We decide to use the termination indicator as necessary to end 
italics or all caps. That looks good. All is going well. This is going to be 
easy! 


e Third: Someone points out that, following these rules, an italic indicator 
could come before an e, n, s, d, or t, causing confusion between the 
italicized letter and a contraction. 


e Fourth: We then consider the letter sign to fix the problem; no, that won't 
work. It's not clear to the reader. 


e Fifth: OK, we'll require uncontracted braille in partially emphasized words. 
That's consistent with the current Braille Formats guidelines. 


e Sixth: That would solve the problem, but how is the reader going to know 


that this is uncontracted braille? Sometimes a contraction not used early in 
the word will be a tip-off. Maybe the problem contraction will be the only 
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one. Then the reader may have to stop to think a minute, but, if 
reasonably well educated, will probably be able to figure it out. It will be 
even easier if the reader happens to know the rule about use of 
uncontracted braille in this instance. How often will one find the word 
"uses" with the final s in italics? | guess, even then, the reader could 
probably tell whether "uses" or "useless" were intended. Sigh... Nota 
perfect fix—especially in textbooks for children in elementary grades. 


e What number are we on now? Well, maybe those hyphens weren't so bad 
after all. Now, why was it we wanted to get rid of them? Oh, that's right, to 
give the braille reader accurate information about the print. How about 
making a symbol meaning "uncontracted braille coming?" That would 
solve the problem completely! Wow! Let's do it! 


e Now what symbol should we use: a. Double letter sign? We could, but 
then we'd have to change the non-Latin passage indicator. b. Three letter 
signs? Too long—it will never fly. c. Letter sign followed by dots 2-3? 
That's kind of nice, but we'll have to be sure we don't want to use the letter 
sign for out-of-place punctuation. That will take a long time. 


e Are we having fun yet? We thought this would be so easy to solve! 


Code building is a more challenging task than it first appears; even simple "fixes" 
become complicated given the complexities of our current codes. The literary 
braille code was not designed to be “extensible” — that is, there are no clear and 
specific rules for building and changing symbols in a logical fashion. Right now, 
every proposed change to the braille code has to be considered individually in an 
ad hoc fashion. 


Current Challenges in Transcription, Translation, and Backtranslation of 
Braille 


As discussed in the first part of this article, braille transcribers often use braille 
translation software to make their work more efficient. Braille translation software 
converts the text in an electronic document into characters that can be embossed 
in braille onto paper or that can be shown on a refreshable braille display. The 
software is written so that, as much as possible, it follows the rules for correct 
usage and placement of braille contractions and symbols. While this software 
can often do a very good job of converting print characters into braille symbols, 
there are still some situations in which a transcriber must intervene in order to 
produce accurate and comprehensible braille. Charts and tables, descriptions of 
pictures, and transcription of spatial arithmetic are some obvious 

examples. However, there are other instances that may be less obvious. 
Currently, human intervention is often required for such details as ensuring 
correct use of single and double quotation marks, proper displaying of acronyms 
and web addresses, handling of long passages written in all uppercase letters, 
removing excessive emphasis indication, correct use of dashes and hyphens, to 
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name only a few. The intervention is largely required because the way these 
items are handled in print can vary greatly from document to document, and the 
rules for their use are far more restrictive in braille than they are in print. 
Transcribers may need to follow additional steps to change an electronic file into 
correct braille in other situations as well, such as changing decorative letters into 
text because the software does not recognize these images as letters. 


A transcriber can produce braille that can be read either on paper or ona 
refreshable braille display. However, as braille readers gain greater access to 
refreshable braille displays, the more common scenario is that they are using the 
displays to read directly from the screens of computers and mobile devices, and 
no transcriber is involved. Using this “on-the-fly” translation without transcriber 
intervention, the texts are often displayed incorrectly. Here are three examples: 


Example 1. According to current codes, e-mail addresses should be 
brailled in Computer Braille Code so that each character in the address is 
clear to the reader. Yet, when reading in contracted refreshable braille from 
a computer screen, an e-mail address will display in contracted literary 
braille, making the characters ambiguous. The user can take steps to view 
the address with no translation applied, but then the surrounding text is 
also displayed in uncoded characters. 


Special symbols often display incorrectly. For example, both the tilde and 
the caret display as dots 4-5. The underline character displays as dots 4-6, 
no matter where it is, creating confusion with the print “dot” that appears in 
virtually every electronic address. These ambiguities can make for garbled 
translations and incorrect information to the reader. 


Example 2. There is often a great deal of confusion among single quotation 
marks, apostrophes, and accent marks. Because of the various ways these 
symbols are used in print, sometimes inner quotation marks display in 
refreshable braille as apostrophes (dot 3), and sometimes a mark that is 
intended as an apostrophe or accent mark is shown as an opening inner 
quotation mark (dots 6, 2-3-6). 


Example 3. When the sentence “H20 = water” is displayed in refreshable 
braille, the fact that the 2 is subscripted is usually ignored, and the equals 
sign may display as a full cell. If, as in this example, it is spaced away from 
the formula, the sentence reads instead as “H2O for water.” What's more, 
the way these situations are handled varies depending upon the screen 
reader or translation program being used; for instance, some programs 
simply display the = sign as the word "equals" instead of the symbol. 
Therefore the braille reader is not getting the same information as the print 
reader of this text. 


Changing print conventions further complicate the job of accurate braille 
translation. There are situations in which it is unclear how to braille something 
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correctly at all according to the current BANA codes. For example, a dollar sign 
most often comes at the beginning of a string of numbers, and the braille symbol 
for the dollar sign in the literary code (dots 2-5-6 when placed before a number 
sign) seems to have been chosen with the assumption that this would always be 
the case. Unlike the print dollar sign, the braille symbol is dependent upon its 
placement for its meaning; in other contexts, dots 2-5-6 has numerous possible 
meanings. How, then, should we handle the name of the pop music sensation 
that is pronounced "Kesha," but who uses a dollar sign instead of an S in the 
middle of her name? 


According to the literary braille code, an out-of-place dollar sign should be 
brailled as dot-4, 2-5-6, that is, dot-4 dollar sign. This seems to work when the 
dollar sign is by itself or when it follows a number or is in a context that refers to 
currency. Since the dot 4 also can stand for some kind of accent or letter 
modification and is also used as a “print symbol indicator,” the braille reader 
might be quite puzzled to have dot 4, dots 2-5-6 turn up in the middle of a 
person’s name. 


For clarity, should the name Ke$ha simply be brailled with an s instead of a dollar 
sign? That solution might work as far as "readability," but it does not provide the 
braille reader the same information that the print reader has. A transcriber 
encountering this name may spell it Kesha, but include a transcriber's note 
indicating that the s is shown as a dollar sign in print. Of course, this solution is 
clear, but it requires the involvement of a transcriber rather than the name 
automatically and correctly displaying on a braille device. 


"But there is an easy fix," the astute braille reader may say. "There is a perfectly 
good symbol for the dollar sign in the math code—BANA should just use that in 
the literary code, too!" The dot-4 s may work because it is unambiguous, and is 
associated with the shape of the print dollar sign. However, a change of the 
literary dollar sign to the one used in the Nemeth Code would require use of 
different rules from those that apply in the Nemeth code. In the literary code, a 
number sign is required after the currency symbol if it precedes numbers and the 
numbers are in the top of the cell. However, in Nemeth code, there would be no 
number sign following the dollar sign and the numbers are brailled in the lower 
part of the cell. Even with this approach, consistency still has not been 
established. 


The example above of the out-of-place dollar sign is not an isolated instance. 
There are countless other examples of words written in ways that make it difficult 
to apply some of the context-based braille rules developed many decades ago. 
For example, brand and company names, such as the sports store FanNation 
and the online service Bookshare.org use creative punctuation and capitalization 
to make their names stand out, but also make an exact representation in braille 
more complex. If a company uses nonstandard symbols in its name and a blind 
person misspells the company name on a cover letter for a job application 
because she did not get accurate information from the braille, what are the 
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chances that person will get the job? Should she have to check the spelling using 
audio or relying on a sighted person to tell her how it is spelled or should braille, 
the primary literacy tool for people who are blind, be capable of giving the most 
accurate information? 


Aside from the difficulties in literary contexts, it is becoming increasingly 
problematic that a completely different code is used for mathematical and 
technical materials. These materials currently do not translate correctly with the 
use of software that does not include transcriber intervention. The need for a 
solution to this issue is ever more urgent as mathematical and computer code 
expressions increasingly appear in everyday contexts. 


To be clear, at this moment there is no known solution that would completely 
eliminate the need for a trained transcriber to intervene in order to verify that the 
format of an embossed braille document is clear and conveys enough 
information about the layout of a print page or document. This is especially true 
in educational materials. Transcribers will likely always be needed for creating 
tactile graphics, complex mathematics and science materials, and other 
complicated written matter. It would be much more productive, however, if, their 
work could be focused on these difficult materials rather than on ensuring that 
each and every dot in the text is correct. The more frequently that human 
intervention and judgment calls must be made, the more likely that braille 
production is delayed, that costs are increased, and that the braille is less 
accurate. 


Another area of concern is backtranslation, which is the process by which 
software converts contracted braille materials into print. Backtranslation is most 
often used when a person creates a document in braille on a computer or other 
electronic device and then either prints the document, e-mails it, or simply 
saves it into a mainstream file type. This process can be especially useful for 
braille-using students who need to write in braille to support their developing 
braille literacy, but who also need for their work to be readable by their non- 
braille-reading teachers and by fellow students with whom they may collaborate 
on projects. In the workplace, braille readers can also benefit from the ability to 
type text using the computer keyboard as a sort of “electronic brailler” by using 
six keys or by attaching other braille devices, thus producing text readable as 
print by someone who does not read braille. The software and hardware exist for 
this need to be met in a seamless way, but there are sometimes problems that 
occur during the process of backtranslation—even when the person who typed in 
braille followed the rules of the code perfectly. Many of the examples given in this 
article are also problematic when dealing with backtranslation. 


When a braille reader reads a document that has been translated from a print 
original, reading itself is a form of back translation. The braille document gives 
the braille reader information about the print original. Ideally, that information is 
both complete and accurate. The more print changes, the greater is the inability 
of the current braille codes to do that job. 
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Conclusion to Part 2 


It is, without question, desirable for users to have independent access to braille 
materials. The proliferation of braille translation software, of braille embossers, 
and of refreshable braille displays has given braille readers more access to 
braille from more sources than ever before. With this greater access has come 
the need to consider multiple factors in the development of new rules and 
symbols for braille. In order to meet the needs of today, which are different from 
past decades, braille needs some systematic changes that will allow for the 
following: 


e room within the code to add new symbols in a systematic way so that a 
braille reader has access to the same information as a print reader 


e consistency of symbols so that correct braille will be shown when reading 
a computer or mobile device screen using braille 


e ability for backtranslation to work more reliably 


e ability to get better "on-the-fly" braille for mathematical/technical material, 
which is increasingly appearing in everyday contexts 


It is clear that BANA cannot continue to adjust the codes on a symbol by symbol 
basis. Our community needs a flexible code that can grow with the English 
language and the changing ways it is represented in print. Braille needs to 
translate into and from print with complete accuracy. To keep up with growing 
demands, braille needs to be produced more quickly and with less human 
intervention than is currently required. BANA is considering solutions that will 
permit this. The third installment of this three-part article will outline these 
potential solutions. 


Page 7 of 7 


